[アップデート] GuardDutyがEKSクラスターへの脅威の検出をサポートしました!

[アップデート] GuardDutyがEKSクラスターへの脅威の検出をサポートしました!

EKSを利用する際のセキュリティ対策の手段が、また一つ増えました!
Clock Icon2022.01.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは!
福岡オフィスの青柳です。

Amazon GuardDutyAmazon Elastic Kubernetes Service (Amazon EKS)クラスターへの脅威の検出をサポートしました!

Amazon GuardDuty now protects Amazon Elastic Kubernetes Service clusters

この新しい機能はGuardDutyにおいて「GuardDuty for EKS Protection」あるいは「Kubernetes Protection」と呼ばれています。
(2020年に追加された「S3保護」機能と同じ扱いになるようです)

EKS Protection機能を使用することで、EKSクラスターに対する疑わしいアクティビティと潜在的なセキュリティ侵害を、GuardDutyを通して検出できるようになります。

設定方法

「GuardDuty for EKS Protection」の機能を利用するための設定について説明します。

GuardDutyの設定

「GuardDuty for EKS Protection」の機能はデフォルトで有効になっています。

当機能がリリースされた後にGuardDutyを有効にしたアカウント・リージョンであっても、以前からGuardDutyを有効にしていたアカウント・リージョンであっても、いずれの場合も「GuardDuty for EKS Protection」機能はデフォルトで有効になります。

現在「GuardDuty for EKS Protection」機能が有効になっているかどうかを確認するには、AWSマネジメントコンソールで「GuardDuty」→「設定」→「Kubernetes Protection」を選択します。

なお、「GuardDuty for EKS Protection」機能を利用したくない場合は、アカウント・リージョン毎に個別に無効化することもできます。

上図の画面で「無効化」のリンクをクリックすると、下図の画面になるので「無効化」を選択します。

EKSの設定

「GuardDuty for EKS Protection」機能の利用にあたり、EKS側で特に設定を行う必要はありません。

「GuardDuty for EKS Protection」機能は、EKSクラスターの「監査ログ」(Audit Logs) を自動的に検査して、脅威の検出を行います。

EKSクラスターには「ログ記録の有効/無効」の設定項目があり、そこには「監査ログ」の記録の有効/無効の設定も存在しますが、ログ記録の有効/無効の設定如何に関わらず「GuardDuty for EKS Protection」機能は利用可能となっています。

2022/01/28 14:00更新

記事初出時に「『GuardDuty for EKS Protection』機能を利用する場合は、対象のEKSクラスターで『監査ログ』の出力を有効化する必要がある」旨の記載がありましたが、正しくは「EKSクラスターの『監査ログ』出力の有効/無効の設定にかかわらず、『GuardDuty for EKS Protection』機能は利用可能」です。

検出できる脅威

「GuardDuty for EKS Protection」機能によって検出される脅威は、以下の27種類の「検索タイプ」に分類されます。

  • CredentialAccess:Kubernetes/MaliciousIPCaller
  • CredentialAccess:Kubernetes/MaliciousIPCaller.Custom
  • CredentialAccess:Kubernetes/SuccessfulAnonymousAccess
  • CredentialAccess:Kubernetes/TorIPCaller
  • DefenseEvasion:Kubernetes/MaliciousIPCaller
  • DefenseEvasion:Kubernetes/MaliciousIPCaller.Custom
  • DefenseEvasion:Kubernetes/SuccessfulAnonymousAccess
  • DefenseEvasion:Kubernetes/TorIPCaller
  • Discovery:Kubernetes/MaliciousIPCaller
  • Discovery:Kubernetes/MaliciousIPCaller.Custom
  • Discovery:Kubernetes/SuccessfulAnonymousAccess
  • Discovery:Kubernetes/TorIPCaller
  • Execution:Kubernetes/ExecInKubeSystemPod
  • Impact:Kubernetes/MaliciousIPCaller
  • Impact:Kubernetes/MaliciousIPCaller.Custom
  • Impact:Kubernetes/SuccessfulAnonymousAccess
  • Impact:Kubernetes/TorIPCaller
  • Persistence:Kubernetes/ContainerWithSensitiveMount
  • Persistence:Kubernetes/MaliciousIPCaller
  • Persistence:Kubernetes/MaliciousIPCaller.Custom
  • Persistence:Kubernetes/SuccessfulAnonymousAccess
  • Persistence:Kubernetes/TorIPCaller
  • Policy:Kubernetes/AdminAccessToDefaultServiceAccount
  • Policy:Kubernetes/AnonymousAccessGranted
  • Policy:Kubernetes/ExposedDashboard
  • Policy:Kubernetes/KubeflowDashboardExposed
  • PrivilegeEscalation:Kubernetes/PrivilegedContainer

出典: GuardDuty Kubernetes finding types - Amazon GuardDuty

検出タイプの名前は「脅威の目的:リソース名/脅威の内容」というフォーマットになっています。

これらのうち「脅威の内容」は以下のようになっています。

「脅威の内容」 説明
MaliciousIPCaller 既知の悪意のあるIPアドレスからKubernetes APIが呼び出された
MaliciousIPCaller.Custom カスタム脅威リストに登録されたIPアドレスからKubernetes APIが呼び出された
SuccessfulAnonymousAccess 認証されていないユーザーによってKubernetes APIが呼び出された
TorIPCaller 匿名化された通信元からKubernetes APIが呼び出された
ExecInKubeSystemPod 名前空間 "kube-system" のポッド内でコマンドが実行された
ContainerWithSensitiveMount ポッドが機密性の高い外部ボリュームへマウントされた状態で起動した
AdminAccessToDefaultServiceAccount デフォルトサービスアカウントへクラスターに対する管理者特権が付与された
AnonymousAccessGranted 匿名ユーザーに対してクラスター操作権限が与えられた
ExposedDashboard Kubernetesダッシュボードがインターネットへ公開された
KubeflowDashboardExposed Kubeflowダッシュボードがインターネットへ公開された
PrivilegedContainer rootレベルアクセス権限を持つコンテナを起動した

脅威の検出の動作を確認してみる

実際に「GuardDuty for EKS Protection」機能によって脅威が検出されることを確認したいと思います。

悪意のある攻撃を実際に行ってテストをするのは難しいですが、いくつかの検索タイプは故意に「脅威の検出」を発生させることが可能です。

今回は2パターンを試してみます。

「カスタム脅威リストに登録されたIPアドレスからKubernetes APIが呼び出された」

GuardDutyの「脅威リスト」へ、自分がインターネットへアクセスする際のグローバルIPアドレスを登録することで、「脅威」として検出されるようにします。

この状態で、kubectlコマンドを使ってEKSクラスターへアクセスを試みます。

$ kubectl get nodes
NAME                        STATUS   ROLES    AGE   VERSION
ip-10-0-3-93.ec2.internal   Ready    <none>   19m   v1.21.5-eks-9017834

特に何ということのないコマンドであり、もちろん正常に実行することができます。

しばらくすると、GuardDutyの「結果」画面に以下のように出力されました。

検索タイプ「Discovery:Kubernetes/MaliciousIPCaller.Custom」の脅威として検出されたことを確認しました。

この時、EKSの監査ログにはどのように記録されているのかを確認します。

監査ログはCloudWatch Logsに出力されているため、脅威が検出された時刻付近のログを見てみます。
(※ 監査ログをCloudwatch Logsで確認するためには、EKSクラスターのログ記録の設定で「監査ログ」を有効化しておく必要があります)

/api/v1/nodesというKubernetes APIがリクエストされたログが見つかりました。
これがkubectl get nodesコマンドを実行した形跡です。

ユーザーの情報などに続いて、sourceIPsに私がインターネットへアクセスする際のグローバルIPアドレスが記録されていました。

このIPアドレスがGuardDutyに設定した「脅威リスト」に含まれるIPアドレスと合致したということですね。

「名前空間 "kube-system" のポッド内でコマンドが実行された」

Kubernetesの名前空間 (Namespace) のうち "kube-system" は、Kubernetesの重要なシステムプロセスを実行するためのポッドが稼働しています。

攻撃者は、システムへの攻撃あるいは攻撃の下調べのために、これらのポッド上で何かしらのコマンドを実行することが考えられます。
「GuardDuty for EKS Protection」機能では、このようなアクティビティを「脅威」として検出します。

名前空間 "kube-system" で稼働しているポッドを確認します。

$ kubectl get pods --namespace=kube-system
NAME                       READY   STATUS    RESTARTS   AGE
aws-node-fzpxz             1/1     Running   0          80m
coredns-66cb55d4f4-6js4f   1/1     Running   0          87m
coredns-66cb55d4f4-lhzqp   1/1     Running   0          87m
kube-proxy-pbf6n           1/1     Running   0          80m

これらのうち「kube-proxy」ポッドへシェルログインを行い、コマンドを実行してみます。

$ kubectl exec kube-proxy-pbf6n --namespace=kube-system -it -- sh
# ls /
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
#

しばらくすると、以下のように「結果」画面に出力されました。

検索タイプ「Execution:Kubernetes/ExecInKubeSystemPod」の脅威として検出されたことを確認しました。

おわりに

EKSを利用する際のセキュリティ対策として「GuardDuty for EKS Protection」機能を活用することで、悪意のある攻撃や攻撃準備を検出したり、脆弱性のある設定が行われていないかを確認することができます。

設定も難しくないため、是非、利用することを検討してみてください!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.